p-PP: discord対応
うまくいかないのではないかと思っているから、LLMがなければ実装に着手しなかった機能
大方針
LLMを使い倒す
しかしコンテキストが明らかに無駄な部分のフィルターの部分は決定論的に行う
例：普段やらなくていいタスクまで/suggestの候補にわたしてしまうと金も時間もかかり結果の精度も落として最悪
妥協
「複雑」な分析はこのソフト上ではやらない
「複雑」の基準は？→gpt-5-miniでできないことは複雑
LLMの進化によって、勝手にこの基準が上がる事を目論んでいる
データの最適化は必要な時だけ行う（例えば1日に1回だけ実行）
超短期の緊急タスクはスコープ外
複雑ではないはず（超短期で複雑なら達成困難なため）。自分でやるほうが早いだろう
TODO
スレッド内で/taskでタスクを更新するときにうまくいっていない
taskIdがundefinedになってる
/task機能
タスク追加・削除・更新ができる
スレッド内だとそのタスクについてそれができる
/task ゴールA機能
ゴールAの次にやるべきタスクと達成基準が示される
完了したら完了になる
すべてのタスクが完了したらゴールがcompletedになる
気分じゃない時にタスクガチャを引き直したい
p-PP: /suggestで 締め切りが近いタスクを表示する
締切を忘れたくない
優先度は低い（妥協の範疇）
よく使いそうだから、別コマンドにしたほうがいいな.../deadlineコマンドの実装
と思ったけどベストはやっぱり/suggestで、それに与えられたことをやっていくとできちゃうのがいい
締め切りが近いとコアタスクに出やすくなるとかがいいか？
締切が近いタスクは「妥協」するわけだから、そこは無視してもいいのかも。 迷う。
GoalはProjectに変更したい
Taskの集合がProject
Taskはsub taskを持つことができる
✅/suggestで maintenanceが出ていたはずなんだけど普通にデフォルトの時間30分ぐらいのタスクが3つsuggestされてしまう
2025-09-27
✅直接データを編集できるeditorが欲しい
https://gyazo.com/f68ac6bc0ce00fabb64b7d6c3da6efa2
18:30 editorで編集してバックアップする運用ができた
2025-09-26
決定論的なフィルタはデータベースを使うのが扱いやすい良いため、データベースに格納することにした
jsonがわかれているのをここまで作成したモデルで表現する設計検討
2025-09-25
新しいアーキテクチャで/suggestできるようになった
✅TaskとPorarisが混在しているので分ける必要がある
discordでまともに動かすために、当初の予定でやらないと思ったことをやるはめになっている。気軽さが失われている。
LLMに全部任せるのが気軽で良かったのに前処理をするはめになっている
機械的処理は決定論的にできる最小限で、あとはLLMに丸投するのが正しい
2025-09-24
機械的に決定できるところとLLMにまかせる協会を作った
例えばidの生成は機械的に処理するようにした
これによって新規のデータ形式にする必要があった
OpenAI Batch APIを使ってgpt-5-nanoで新規のデータ形式に変換した
2025-09-22
複雑になってきたのでアーキテクチャを整理する必要がある
新機能を載せるま絵に機能を整理する
linterを入れたらanyが爆発したので地道に直させる
formatter/linterをいれる細かく大規模に書き換えられた時に差分が見やすくて便利
Claude Codeは実装で使うので、実装中はタスク管理システムを運用させられないという悩みがある
どこに保存するか？
discord botのようにdiscord対応させる
コマンドは
モデルはgpt-5 miniを利用する
聴講が必要な場合は手元でChatGPTでバラしてから入れることを想定する
Storage per Durable Object 10 GB
十分すぎる
バックアップは手元ダウンロード
バックアップのためのエンドポイントも作成する
タスク操作
/task message <内容> タスクを追加
/goal （北極星の確認・更新）
バックアップ/復元
/backup export 全データをJSONでダウンロードリンクにして返す
/backup import <file> JSONをアップロードして復元（管理者限定）
最小構成なら
/task add, /task list, /task done, /task suggest, /goal set, /backup export
だけでも実用に耐えると思います。
流れユーザー入力を受ける
botの役割
その文字列をそのまま gpt-5 に渡す
gpt-5には「自然言語をYAML編集に変換する」プロンプトを与えておく
出力は JSON か YAML Patch 形式に制約して返させる（structured outputs）
gpt-5はタスクを分析し、以下のようなyamlを返す
code:yaml
{
"action": "add",
"file": "core_tasks.yaml",
"task": {
"title": "レポートを書く",
"deadline": "2025-09-19",
"priority": 1,
"status": "未着手",
"duration_min": 90,
"category": "司法試験"
}
}
Botがこれを受け取って core_tasks.yaml を編集する
Botの編集処理
該当するYAMLファイルを読み込み
指定位置に追記／更新
ファイルを保存
JSONLにしても良さそうだな
JSONやyamlは全部読み込まないと構造不明
実装経過
機能拡張のためにアーキテクチャを検討して変更した。丸一日かかった。
次はドメインを確定させていく
不定形のタスクデータがプログラムを構造化する際に障害になっている
必ず必要なデータとオプショナルなデータに分けて、LLMが自由に扱える情報はオプショナルなデータ（例えばノート）に押し込める方針でドメインを確定させていく
スレッド作成時にJSONの詳細を出すようにした（gpt-5-nanoが整形している）
https://gyazo.com/13e3214dfa54e3c06277301fdf91a63f
/taskでタスクの更新をできることを確認
idをLLMが適当に作らせるのではなくnano IDで生成するように変更。既存データをmigration
不定形のJSONを扱う部分はすべてLLMに任せる方が良さそうだ
不定形のデータを扱えるのがタスク管理システムとして珠玉の部分だが、これを構造的に扱おうとすると大変な上に、どうしても良さが消えてしまう。だからすべてLLMに任せる
基本的な実装が進んだ
設計思想
Single Source of TruthはDO上のデータ
タスクなしの場合は捏造せずに、なしが表示される
https://gyazo.com/fdbcd10ab079598db28c62f155105774
GitHub上のJSONLから初期化ができる
DO上JSONLをExportができる
個人的な応答をする際にはEPHEMERALフラグを使う
他人にチャットが見えなくなる
データバックアップの流れ
/initを叩くとdata/jsonlが読み込まれる（初回）
discordで編集処理
以下のコマンドでdata/jsonlに保存される
$ opr node scripts/convert-export-to-import.js
固定値がかえるようになった
https://gyazo.com/71e180f110be1b20aa051c3f23a501d4